“Identity providers” are systems that create, maintain and manage identity information for users, systems, and/or services and provide authentication of such users, systems and/or services to other service providers (e.g., applications). In the simplest case, a user has one digital identity for one application or website (e.g., users may log into Facebook® using their Facebook® identity or log into Yahoo® using their Yahoo® identity). However, many services operate within a federation or distributed network, where such services trust an external identity providers (often an otherwise unaffiliated party) that users and servers rely upon when establishing a dialog for authentication. Further, many websites and applications permit use with digital identities from multiple identity providers. Thus, it is necessary for applications to discover which identity provider end-users want to use.
In the consumer space, typical practice is to display a list of names, pictograms or user-selectable buttons, each button representing an identity provider. For instance, the buttons may read “Sign in with Facebook®,” Sign in with Google®,” and the like, wherein Facebook® and Google® represent different identity providers. This type of experience is often confusing for users and may hurt the destination site or application's brand equity, as the user interface becomes crowded with logos from different, and often competing, providers.
In the organizational space (e.g., enterprises, schools, etc.), online service providers typically set up addresses that are specific to each organization. For example, employees of the Contoso organization may visit http://contoso.some-calendar-app.com to access an online calendaring application tailored to Contoso users. An alternative is for service providers to set up a shared landing page on which end-users are prompted to enter their organizational email address as a user identifier. The website or application then places one or more Application Programming Interface (API) calls to determine the appropriate identity provider based on the domain of the email address entered. The application then redirects the user to the proper identity provider for authentication.
While this approach works well in fairly constrained environments, such as enterprise applications exposed only to internal users and users from a select number of partner organizations (e.g., vendors), the approach becomes more complex when these organizational services operate in the cloud with an “open” model, where there is no preconceived knowledge of the appropriate identity provider. For one thing, there is no universal identity provider discovery API on the Internet that would allow a website to determine the appropriate identity provider based on an email address. Furthermore, the pictogram or selectable list of identity provider options approach is not ideal as end users are often unaware of the name of the provider that manages their organization identity (for instance, a Contoso employee may not know that Contoso's IT department has chosen Identity Provider “A” to manage their employees identities and thus would not be able to select the proper button from a list that includes multiple enterprise identity providers).
This problem becomes even more complex to solve for websites that cater to both organizational and personal identities as the same email address may be used by someone as a sign-in identifier for many different online identities. For example, a user named Kelly might use her work email address, kelly@contoso.com, as a sign in string for her Facebook®, Google®, Amazon®, and Microsoft® accounts, each being associated, however, with differing further authentication credentials (e.g., passwords). When presented with an authentication option, Kelly might be quite familiar with her employee email address that she utilizes on a daily basis but she may not remember which of her accounts having this email address as a digital identifier she utilized in creating an account for another website or service. Further, it becomes difficult, if not impossible, to disambiguate Kelly's digital identity based on the email address alone in such situations using traditional approaches.
As a result, many websites and applications have simply renounced offering an integrated Identity Discovery experience. Some organizational services have chosen to display a collection of user-selectable options that confuse end-users as they don't know which option to select. Other organizational services have simply set up different entry points (e.g., website addresses) for different organizations. For instance, if Contoso uses Box.com®, a provider of cloud-hosted file servers that caters to organizations, to manage its employees' files, employees of Contoso are often unable to sign into BOX® from the website's homepage, www.box.com, and must instead use a dedicated URL like https://contoso.box.com/login) for authentication. This is cumbersome to say the least.